AI technologies for SOC automation

In the early 2000s, we began applying machine learning algorithms to detect malicious software. Since then, attackers have improved their methods. Today’s targeted attacks are characterized by high stealth — in particular, making minimal use of malware that can be detected by antivirus. Instead, many attackers make use of social engineering to gain initial access, and then exploit system misconfigurations and legitimate software for lateral movement and persistence in the compromised infrastructure.

Detecting such attacks requires collecting and analyzing a large amount of data on the behavior of devices, applications, and users in the corporate network. And every time suspicious activity is detected, the incident has to be verified as an attack or deemed legitimate activity. As the number of assets in an organization grows, the volume of collected telemetry also increases, increasing the load on analysts working in Security Operation Centers and MDR services.

Automation based on AI technologies makes it possible to significantly simplify this work in several areas:

• Triage: prioritizing alerts about suspicious events in MDR/XDR/SIEM telemetry, filtering out false positives.
• Behavioral anomaly detection: identifying the signs of account theft, host compromise, DLL Hijacking attacks and other malicious activities.
• Data presentation: summarizing and interpreting command lines, incidents, and TI reports.
• Threat hunting in natural language: translating analysts’ hypotheses into SQL queries.

Below, we describe how these AI technologies are implemented in practice in our products and services.

Automatic Analysis and Prioritization of Alerts

The infrastructures of our MDR service clients generate billions of security events daily. The data collection system identifies suspicious events based on special detection rules and reports this potentially malicious activity to analysts in the form of alerts: several hundred thousand messages annually. However, only about a tenth of these alerts will relate to genuine security incidents.

Thus, analysts face the task of filtering out the ‘false alarms’ which make up the majority of alerts. To do this, we developed AI system called Auto-Analyst. This supervised machine-learning system trains on alerts marked with the verdicts of SOC analysts. The goal is to confidently identify false positives generated by legitimate network activity.

Machine learning here is based on CatBoost — a popular gradient-boosting library. The trained Auto-Analyst filters alerts and only forwards for human review those with a probability above a specified threshold of being a genuine incident — this probability being determined by the acceptable error rate. This results in around 30% of alerts being handled solely by the AI, freeing up the SOC team’s time for more complex tasks. The alerts that do reach human analysis have been prioritized, allowing analysts to focus on the most critical first.

More details about the practical nuances of Auto-Analyst's work (controlling training data, selective review of results etc.) can be found in a separate article by our experts.

Anomaly Detection in SIEM

The essence of this approach is to use telemetry obtained during the "healthy" functioning of the system to train an AI model that will then signal deviations from normal behavior.

Using such algorithms in large distributed systems is complicated by the enormous number of parameters that need to be considered when building the model. And such models can produce large numbers of false positives: in an organization with thousands of users, many cases of atypical behavior may be legitimate.

However, this approach can be used very successfully for separate assets and processes where it’s possible to build a sufficiently accurate model of normal functioning.

Anomalous Event Chains

In this case, data on typical sequences of SIEM correlation rule triggers is used to build a model of normal behavior. Frequent triggers of the same sequence are usually false positives (e.g. automated administrative script execution), these can be used as an indicator of typical activity within the infrastructure.

By building a profile of typical host behavior as a set of probabilities of triggering certain rules, our AI system can evaluate how typical or atypical each new event chain is for the given infrastructure. Detecting an atypical chain leads to the system increasing the priority of the alert, drawing the attention of security specialists for more detailed analysis.

Account Theft

Another anomaly detection technology enables the detection of potentially unauthorized activity of user accounts. Here, the ML system uses pairs of entities such as `account-IP`, `account-host`, `account-country`, etc. to create profiles of typical account behavior.

An attacker using a stolen account will usually disrupt the common activity pattern. Attackers log in to the system from unusual addresses and then look for ways to move laterally or escalate privileges in the system, visiting nodes in the infrastructure that the legitimate user of the account won’t have visited. The AI system detects such anomalies and collects the necessary context in an alert, allowing analysts to quickly respond to such incidents.

DLL Hijacking

DLL Hijacking is an attack technique in Windows OS where attackers replace a library called by a legitimate process with a malicious one. Detecting such attacks using classic security solutions isn’t easy because the malicious library executes within the trusted address space of a legitimate process, so this activity may look to a security solution like a trusted process. It's no surprise that the number of attacks using DLL Hijacking has increased significantly in recent years.

To build an AI model that distinguishes between malicious and legitimate library loads, our experts identified a number of features that occur in suspicious cases: wrong library location, wrong executable location, renamed executable, changes in the library's size and structure, lack of signature, etc. For the training sample, we used DLL load data provided by our internal automatic processing systems, and anonymized user telemetry from KSN.

More details about the training process of this model can be found in a separate report. Even at the pilot stage, this technology has helped prevent several attacks in our clients’ systems.

AI Assistants Based on Generative Models

All the previous examples concern the use of AI as a classifier: given a new information object, the model outputs it as belonging to a certain class (‘it’s a dog‘). Such ML systems are usually trained on a limited sample of data directly applicable to the task.

Generative AI works ‘in reverse’. The system receives a certain type of desired result as a query (‘draw me a dog‘) and outputs new information objects of the desired type. To do this, the system uses extensive ‘knowledge’ in the subject area, obtained as a result of pre-training a Large Language Model (LLM) on huge arrays of public data.

This allows the application of LLM-based systems to a wide range of tasks, including working with unstructured data. Today’s LLMs are particularly good in handling text processing tasks — such as translation, interpretation and summarization (i.e. creating a brief version of the original text while preserving key ideas).

To solve similar text-processing tasks in security products and services, we have developed our own AI assistant technology. This technology prepares data for queries to LLM, forms and sends queries, processes results and passes them to analysts while ensuring the entire communication is secure.

The AI assistant can work with any LLM chosen by the client, according to their tasks and requirements. For example, сloud models are usually more powerful than those deployed locally, but using locally deployed models avoids transmitting confidential data to third-party services.

Interpretation of Command Lines

An obfuscated command line is a common type of suspicious event requiring close inspection by an analyst. Attackers use such lines to give their instructions directly to the operating system of the attacked host while avoiding detection. To disguise malicious commands, they use coding, syntax manipulation and many other obfuscation methods, making it difficult to identify the true intentions of the command author.

Our AI assistant first performs static de-obfuscation of the suspicious line. Then it sends a series of queries to LLM to explain all the command line parameters. Finally, the assistant presents an analyst with a summary: what the line does and how dangerous it is.

Summarization of Incident Data

To automate incident response, today’s SOC will use functionality of Incident Response Platform (IRP). This program collects all data related to an incident into one card, including related security events and artifacts.

However, such a collection of data can be very large, and manual analysis of all incident details takes time. Moreover, there are situations when analysts need to recall old incidents - which requires the reassembly of pieces of old puzzles.

The GenAI assistant significantly simplifies this work. It collects all telemetry related to the incident and, using LLM, creates a brief explanation of what happened in the case, including the initial attack vector and the attacker’s actions throughout the incident, together with recommendations on how to respond.

Summarization of Threat Intelligence (TI)

When investigating an incident, analysts often refer to additional sources of information about the threat in question. One such source is our Threat Intelligence Portal (TIP) which contains over five petabytes of TI collected by Kaspersky over more than a quarter of a century of threat detection work: hashes of malicious files, statistical and behavioral characteristics, IPs and URLs of command-and-control centers, TTPs of hacker groups, etc.

A typical scenario for working with the portal looks like this. An analyst uploads a suspicious sample found during incident investigation and runs it in the portal's sandbox. As a result, they receive detailed analytics: verdicts and hashes of detected malware, domain addresses they contacted, downloaded files from the Internet, etc.

All this data can be used as parameters for searching for additional TI from open sources. For example, the portal can show reports on an APT group that uses the same C2 addresses as those detected when detonating the sample in the sandbox. This gives the analyst additional IoCs to check in their infrastructure.

However, studying disparate TI reports can take a lot of time, especially if they are written in different languages and formats. Our AI assistant creates a structured summary of TI reports that shows how a given indicator is related to a specific group, where and when it was active, what techniques it uses, etc. Similarly, the AI assistant can create a structured description of a given APT group based on OSINT data.

Threat Hunting in Natural Language

When an analyst wants to get additional data on the ongoing incident or proactively identify a threat based on newly received indicators, he must formulate a query to some log storage or SIEM/EDR/XDR database, where security events are collected. However, translating the analyst's hypothesis into SQL queries with precise syntax and correct parameters can take a significant amount of time and slow down investigation and response processes.

Our AI assistant allows analysts to formulate queries to the database in natural language, i.e., literally at the level of the hypothesis. The analyst may for example say, "show all events that occurred yesterday on such-and-such hosts, where an executable file with such-and-such a name was involved." On receiving this request, the AI assistant uses LLM to select the necessary fields from the data model and then issues an SQL query to the database. Before actual execution, analysts can review the AI-generated query, validate its logic, and adjust parameters or syntax if they wish.